
-------- TML Message #1732 --------

Archive-Message-Number: 1732
Date: Thu,  8 Nov 90 22:22:58 -0500 (EST)
From: William Dow Rieder <wr0k+@andrew.cmu.edu>
Subject: One giant leap...

	I recently acquired Challenge 45, which has the "One Small Step" rules
for pre-gravatic space flight.  Overall, I think it is a very good
article.  However,
one of the drives listed, the Fusion Rocket, is an amazingly good drive,
even for
higher tech ships (I believe it was taken directly from COACC, which I do not
have, so I won't hold it's peculiarites against the writer of the article).

	The stats are as follows:
Thrust: 195 tons	Mass: 4 tons	Volume: 1 kl
Fuel: 0.005 kl/hour	Power Output: 3.9 MW
Cost: 350,000 credits

	In the description, it is noted as having an advantage over grav
thrusters, but it "loses its last tangible advantage" when manuver drive
thrusters are introduced at TL 11.  I disagree.  On the contrary, it can not
even be fully used until the introduction of inertial compensators at TL10
makes it possible to use the high accelerations it can generate without
crushing the crew and passengers of a ship.
	For ships without armor, it is far superior to the standard manuver
drive.  For example, assume a 100 ton ship that masses 1 ton per kl (total
mass 1350 tons) wishes to increase its max acceleration from 1G to 2G.
The standard method is to add 3 thruster units and ~12 kl of TL15
powerplant to power them.  This has the following stats:

Fuel needed	Volume(kl)	Mass(tons)	Cost(KCr)
0.108 kl/hr	52.5		129		4,500

A Fusion Rocket with a thrust of 1350 tons, enough to increase the max
acceleration from 1G to 2G, has these stats:

Fuel needed	Volume(kl)	Mass(tons)	Cost(KCr)
0.035 kl/hr	7		28		2,450

As you can see, it costs less, masses less, takes up less space, and is
cheaper to boot! Oh, yes - it produces 27 Mw of power too...
The only reason I can see to use thrusters on an unarmored ship is to
be able to land and take off without scorching the surroundings.  My
suggested solution is to retain a 1G standard drive, and get the rest
of the acceleration from the Fusion rockets.
	Fusion rockets also make it very easy to get acceleration
over 6G: you can get 20G easily, 30G with some work, and 40G if
you really want it.  This makes it possible to outrun missiles, let alone
system defense boats, patrol cruisers and navy ships.  Figuring out
the exact performance can be a pain though, because you can get
up to a significant fraction of c within a couple of weeks if you want.
I even was able to design a STL starship that could cover 300 parsecs
in less subjective time than a jump-6 ship.  Of course, ~1000 years
will have passed for the rest of the universe, but it might be a handy
way to get away from the Rebellion...:-)
	Alas, this drive has a physics nullifier box (its easy to miss -
its by the fuel intake :-)).  To get 195 tons thrust for an hour with
just 5 liters of reaction mass would require a exhaust velocity well
in excess of the speed of light.  A more reasonable fuel rate would
be ~0.5 kl/hour, I haven't worked out all the details yet.
	Finally, a merchant ship design that I modified to use the
fusion rockets:

	Torch class merchant, TL 15

Item					Power	Volume	Mass	Cost(Kcr)
- - -------------------------------------------------------------------------------
200 ton hull, config 4SL,   armor 40G	-	[2700]	323.4	7,871
Powerplant - Fusion (0.225 kl/hour)		[450]	25	50	5,000
Jump-4 (10 units) (fuel 675)		-	135	270	30,000
Manuver-1 (4 units)			280	54	140	2,800
Fusion Rocket - 24,180 TT, fuel 0.62/hr	[483.6]	124	496	43,400
Comm. & Sensors   (standard)		0.9	0.7	0.5	1,652
Environ & LS    (not fuel - 1700 kl)		6.8	22.1	22.1	867
Inertial Compensators    (whole ship)	54	27	54	675
Grav Plates (not fuel - 1700 kl)		85	17	34	850
Computers - 3 x 3				-	12	3	11,400
5 Holo HUDs				0.1	5	2.5	500
Weapons: 2xPlaser,2xMissile,2xSand		504	27	18	3,000
20 Missiles				-	2	1	400
6 Small Stateroooms			-	162	12	240
2 Elow Berths				-	54	4	200
3 Airlocks				-	9	0.6	15
Fuel Purif. Plant (200kl/6hrs)		1	40	80	30
Fuel and scoops				-	1000	(70)	203
Cargo (~73 tons)				-	990.2	(990)	-
					---------------------------------
					931.7	2700	1511.7	109,103
Mass = 1511.7 tons empty, 1581.8 with fuel, 2572 with full load of
cargo	(x 0.8 =	87,282)
Spare power = 1.9  MW	Lasers can only be fired when Fusion rockets are on.

Acceleraton:	17.0 Gs empty
		16.2 Gs with fuel
		10.4 Gs with full cargo load
Endurance:	1 Jump, 30 days basics and 1G, 10.9 days combat
and full acceleration.

					W. Dow Rieder

 	When the only tool you have is a hammer, all your problems
start to look like nails...

-------- TML Message #1733 --------

Archive-Message-Number: 1733
Date:     Thu, 8 Nov 90 22:58:44 PST
From: Orcinus orca <jokim@jarthur.claremont.edu>
Subject:  Re: Gnu Traveller--change a little more than the name

Wow.  Looks like you guys are trying for a massive overhaul.
I think you might not be seeing the forest for the trees.
You're not just limited to fixing GDW's rules and compiling
errata sheets to send to GDW for a paltry salary.  You
could (and only the first is serious):

1.  Start a subsidiary company that sells supplementary
Traveller material.  I know, that would take money.  But
it looks like you're changing a *lot* of things:  character
generation, weapons and combat, vehicle design, trade and
commerce.  You're also thinking of a new name, are considering
changing the Traveller background universe, and someone has
even mentioned desktop publishing.  There isn't much left
to change!  Well, you're keeping jump drives and the jump-6
limit :-).  Just keep in mind that instead of sending everything
you make up to GDW to publish as a one-shot deal (and one-shot
payment), you can put a little capital into it and keep the
money flowing in.

2.  Hostile takeover of GDW.
3.  Screw Traveller and start your own company with its
own Sci-Fi game.

P.S.  I have an uncle who owns a printing shop.
- - --
John H. Kim
jokim@jarthur.claremont.edu
uunet!jarthur!jokim

-------- TML Message #1734 --------

Archive-Message-Number: 1734
From: Jim Cheetham <jim@oasis.icl.stc.co.uk>
Subject: Vehicle Designs
Date: Fri, 9 Nov 90 10:25:19 GMT

( Hi Paul ... see you've changed the .signature a bit ...)

Yes, about the vehicle designs ...
I admit that I'm not going to be using the Vehicle designs
myself, I'm in this game for the background stuff mostly.
As such, it's a shame to see so much bandwidth used in transmitting
them. However, it's not too difficult to skip past them
to get to other more interesting stuff.

Paul, I think that you can use MH on your machine - use that
to burst each message and then automatcially refile the vehicle
designs elsewhere - they all have a distinctive Subject: .

Other people - it's unlikely that you're using a pager that can't
search for text - usually using the / command. Just skip over
the stuff by searching for the next message - /From:

(Oh yes ... some of you use VMS ... errr ... not too sure about
that, been many years since I read mail on VMS. Perhaps someone
could suggest a method?)

Oh yes, people, can you make sure that the Subject: line is indicative
of what's in the messages? I don't have much time to spend reading
mail, and so I skip many articles based on their Subject: ...
Perhaps I miss the occasional worthwhile message, but it beats
reading reams of non-relevant (to me) stuff.

(Have I finished yet? Ah, yes ...)

- - -- 
A la prochaine ...
        _____               ____  _               _   _  
       (__ __) o  ______   (  __)( )_  ___  ___ _( )_( )_  ___   ______
      (____)  (_)(_)()(_)  (____)(_)_)(__=)(__=) (_)_(_)_)(___)_(_)()(_)
Jim Cheetham, jim@oasis.icl.stc.co.uk, BRA01 0344 424842 x3121 (ITD 763 3121)
              *********************** - as from December 1990 onwards,
              use jim@oasis.icl.co.uk due to corporate restructuring.
    #include <std/disclaimer.h> /* To keep the company lawyer happy */

-------- TML Message #1735 --------

Archive-Message-Number: 1735
Subject: Annic Nova
Date: 9 Nov 90 12:07:38 MET (Fri)
From: Karl-Koenig Koenigsson <@wrgate.wr.TEK.COM,@sunic.sunet.se:kko@spodv2.uucp>

Hi there,
          I wonder if anyone might give me some hints on
prefab adventures, suitable for sessions about a day long.
I (and my players) don't have the time for Grand Campaigns,
but would like to get together once in a while and play a
little MT.

  If the adventures on the other hand are still small in size,
but can be set in a larger scheme, it would be preferable. This
means that I can keep a sense of coherence in the overall background
and still get away with one session a month... ;-)

  I have played the Annic Nova with them for a start. They liked
it, but most of all: I liked to GM it! It was an intrigueing
adventure, and gave excellent oppurtunities for good roleplaying,
as well as real problemsolving for the _players_ rather than the
_characters_ (Which is always a problem for the GM, as of which
you are probably already aware...)

  To rephrase my question: is there any adventures of the
same _kind_, ie. concerned mostly with rational thinking,
and deduction, rather than blasting the problems away. ;-)

  Thanks a lot!

+-------------------------------------+-------------------------------------+
| Karl-Koenig Koenigsson              | koenig@pelle.tdb.uu.se              |
|                                     | kko@pks.tds.philips.se              |
| All opinions stated are my own      |"There's something fishy in Denmark" |



-------- TML Message #1736 --------

Archive-Message-Number: 1736
Subject: TDR (Traveller Done Right)
Date: Fri, 09 Nov 90 12:00:18 EST
From: Robert P Poole <tarquin@athena.mit.edu>

I think this is a good idea.  Suggestions:

(1) TDR is the name to go with.  GNU is out, because it is registered and
belongs to the Free Software Foundation.  (Yup, it's true, Richard will get on
our asses -- I mean Richard S.)

(2) As for "physics problems": I have to laugh.  How, pray tell, do you justify
hand waving?  Look, the Jump Drive is necessary for the game to work, and if
you insist that all messages are carried by starship courier, then the game
works well and balance of play is preserved.  I'm not sure why people are
flaming about Jump-7 ships.  As for the maneuver drives and such -- go ahead,
fix them if you must.  I'm a physics major, I could probably do some
computations in my copious free time and see how plausible some of these things
are.

(3) I am very much in favor of making this system work with the currently
designed MegaTraveller universe.  I think the shattered Imperium is a great
setting for adventures, and I like the alien races that are covered by MT
supplements.

(4) I suggest that TDR be written using TeX or LaTeX, since these text
formatters are (a) free, (b) nearly universal [if you don't have TeX or LaTeX,
you can get one or both from a variety of ftp sites for almost any machine,
including your garden-variety PC], (c) EMACS has a TeX mode built in, (d) TeX
and LaTeX are particularly good at formatting publication-quality text and at
formatting any kind of tables and mathematical formulas, both of which are
copiously present in Traveller.  I would even be willing to take tables that
people typed in and "TeX-ify" them.  Since previewers are available for just
about any machine, you can run your TeX document through TeX and then run the
previewer to see how good or bad it looks.  Granted, we could also use
MacIntrash WYSIWYG word processors, but let's face it, this short-circuits a
lot of UN*X users who would be using their resources.  Besides, there is a TeX
package for the Mac called TeXtures.  It's quite good.  (It's not free, but
that's what happens when you have to majorly rewrite software to run under a
fascist operating system.)

Well, that's what I have to add to the discussion.  Now all we have to do is
get organized.

Robert P. Poole                       tarquin@athena.mit.edu
46 Massachusetts Avenue               MIT Course VIII
311B Bexley Hall                      "We make Idols of our concepts, but
Cambridge, MA  02139                   wisdom is born of wonder."
                                         -- St. Gregory the Illuminator

-------- TML Message #1737 --------

Archive-Message-Number: 1737
Subject: Starship designs and digest bursting
Date: Fri, 09 Nov 90 10:09:28 PST
From: James T Perkins <jamesp@metolius.WR>

These seem to have become quite an issue lately.  I think it has come up
because there is a lot of interesting discussion and a large volume of
starship designs at the same time.  Traffic has been very high this week
(gee, THANKS metlay :-).  Naturally, messages get jumbled up and
disordered on their way to the TML.

What Carl Rigney proposed is this: all the messages that have starship
designs are sorted to the end of the digest.  What do you all think of
this? Unless there is outcry or a better idea, I am hoping to implement
this before the middle of next week.  Personally, I don't find the
complete designs offensive, as long as they are placed at the end.

I should be able to tell if a message contains designs, by seeing if it
contains most of the strings gauranteed to appear in a USP: "Accom" and
"Commo", etc.

One of the downfalls of this scheme is that the archive message numbers
may not appear in serial order, due to the grouping of ship designs to
the end.  Instead, there will be (in serial order) all non-design
messages followed by all design messages.

As for bursting digests, I looked at Ted Kim's digest burster earlier
today.  I realized that it is more complex than it needs to be, so I
came up with one of my own.  It works great on the new-style digests and
archive bundles.

It is written in C and assumes a Unix-like mail environment, so those of
you using other sorts of systems will still be out of luck.  Still, you
would have something to start from, and I would hope you'd share the
results of your work.  It will be included in a later message to the TML
today.

James
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Traveller Mailing List Administrator	     James T Perkins @ Tektronix, Inc
traveller-request@metolius.wr.tek.com	     Beaverton, Oregon, USA
uunet!metolius.wr.tek.com!traveller-request  "Load Auto/Evade, Beowulf!"

-------- TML Message #1738 --------

Archive-Message-Number: 1738
Date: Fri, 9 Nov 90 10:50:27 -0700
From: FELLOWS STEVEN B -5 CR <sfellows@slate.mines.colorado.edu>
Subject: Travelling and Cargo Cost example

Names:

I can't think of any one name that I like more than others, but my
votes go to:

Rebel Traveller, and TDR

Also, how about:  Travelling.


One thing I would like to point out:

  Someone mentioned that they could not understand why it would cost 
different amounts of money to ship different material.  100 tonnes of feathers
as oppossed to 100 tonnes of machine parts.  Well, in my system, it would cost
more for the feathers, since they take up more volume.

  Example:  the macinery takes up 10 cubic metres, but the feathers take up 
1000 m^3.     At 5 Cr/tonne/ly in my game, the feathers would actually be
5000 CR/ly and the machine parts 500Cr/ly   .  I take the greater of volume or mass.

Steven B. Fellows
sfellows@slate.mines.colorado.edu.



-------- TML Message #1739 --------

Archive-Message-Number: 1739
Date:     Fri, 9 Nov 90 13:32:52 EST
From: "Robert S. Dean" <rsdean@crdec8.apgea.army.mil>
Subject:  Thinking about Rules Revisions

I apologize for including the complete text of two previous messages here.


> From: "Mark F. Cook" <markc@hpcvss.cv.hp.COM>
> Subject: (1715) Help!! Trade & Commerce nightmare!
>
>  Well, I've put it off for as long as possible, but I've finally had to
>  bite the bullet and dive into the Trade & Commerce section of the MT Ref's
>  Manual.  It's even worse than I thought!!  Help me out here folks, 'cause
>  I've got a TON of questions.  (Well, a couple Kilos, at least :-)).
> 
>  Starting with Part 5 "Freight and Cargo" (pg. 50), does the AVAILABLE
>  LOTS table apply to Freight, or Cargo, or do you use it once for each?
>  Also, how do you determine lot size for freight?  The note that refers
>  to "Lot Size" only mentions cargo.

     My interpretation of this, and I don't have my rule book with me, is 
that you would be correct in assuming that you are to use it once for each,
cargo, and freight.  Determine lot size for freight using the same table.  
This brings up a comment I made months ago.  According to older versions of 
rules that used essentially that same lot size table, the lot sizes for major
and minor cargoes were 1d6*10 and 1d6*5, not 1d6+10 and 1d6+5.  Since the
latter means that a typical 600+ ton ship can only fill its hold at a Pop9+
world, heading for another Pop9+ world, I have been using the former system.

>
>  Next comes the REAL mess: cargo cost.  As nearly as I can tell, the rules
>  which govern the determination of cargo cost (to the speculator) on pg. 53
>  MAKE NO ALLOWANCE FOR CARGO TYPE.  This means that a 100 Kl. lot of ferrous

You've grasped the rules firmly, I see, and discovered the thorns in the
process.

>  metal ore costs the same as a 100 Kl. lot of electronic parts, which costs
>  the same as a 100 Kl. vehicle, which costs the same as 100 Kl. of TL-15
>  mud!  It's all based on volume (or weight), and modified by trade code,
>  tech level, and source world starport type.  What a crock of SH*T!  When
>  I saw the spec. cargo entries on pg. 13 of "Knightfall", my initial
>  reaction was, "Yah!  That's how it's suppose to look!"  Unfortunately,
>  you can't get there from here.

If you have Knightfall, you can look up the quick fix system, not perfect,
subject to your own common sense modification, but available between now
and next week.
>
>  What's a ref to do?  (BTW, I need answers BEFORE the middle of next week.
>  Otherwise, James and Richard's new characters in my campaign may be standing
>  in the unemployment line.  ...and I think one of them bites!! :-))
>
>        Mark F. Cook

  ---------------------------------------------------------------------
> From: George William Herbert <gwh@ocf.berkeley.edu>
> Subject: (1705) Fixing Maneuver Drive Physics...
>
>
> I've been working on a fix for justifying the volume-based maneuver drives...
> It goes something like this:
>	Maneuver drives (not grav thrusters) don't actually produce thrust
> or force.  What they do is distort the local gravity field...not just play 
> with it like lower tech grav, but actually forms a gravitational gradient
> (volume of warped grav. volume is proportional to the maneuver drive
> volume...) around/within the ship.  The 'thruster plates' garbage can be
> explained away through pseudogobbldeygook 8-) .  The Inertial Compensators
> take this field (which should be uneven, stronger closer to the drives...)
> and even it out so that everything in the ship doesn't fall towards the
> front 8-) .
>
> Comments? Suggestions? Let's hear 'em, I'd prefer not to have to junk the
> current rules, even if they need revision (yay metlay).
>
> - -george

My suggestion for this is as follows.  I haven't got my rule book with me, so 
I'm winging it on numbers.  Suppose we did this:  The TL9 grav spaceship
drives are functionally equivalent to the StdGrav of the smaller vehicles
table.  I'd make the assumption that power consumption remains constant
per ton of thrust, but size and weight can be decreased in some sort of scale 
efficiency like the power plants.  This means that a Grav Maneuver unit
produces 650 tons of thrust for the 65MW of input power.  You could calculate
the minimum "economy of scale" size from the 1G drive for the 20 ton hull...
however many units that size takes up is where the crossover point for
advantageous size/weight would be.  Now, for a spacecraft of TL9-10, things
become very easy.  You merely calculate a thrust, same as always, and
divide by the LOADED weight of the vehicle to get an acceleration, same as
for any smaller grav vehicle.  If your thrust isn't equal to the local gravity
times your loaded weight, you can't land or take off from that planet.
Simple enough, right?

Thrusters would then work like this...they simply become improved grav units
that can work away from a gravity well by some double talk I don't want to
worry about right now.  The price you pay for this ability is increased power
consumption...70MW for what 65MW of grav would do. So 13.5 kl of thrusters
would weight 35 tons, consume 70MW and produce 650 tons of thrust not reduced
by distance from a planetary gravity well.  To keep everything consistent, you
can decree that the minimum size these things can be built at is the one that
corresponds to 1G for 20tons, and if you want to stick that (6kl??) unit
and the power to drive it in a 13.5kl vehicle, go ahead.  Multiply your
thruster units by 650 tons, divide by the LOADED weight of your vehicle and
you have your maximum acceleration.  If your thrust is less than your loaded
weight, you don't land on planets with standard gravity, and so forth...
Still simple enough, right?

If you actually do the calculations involved for a couple of examples of ships
with minimum armor, you'll find that the accelerations work out to be close to
the maneuver drive rating, which implies that that is how they were worked
out in the first place.

Anyway, that's a simple fix that will enable you to dispense with any really
bizarre explanations of why the drives were sized the way they are.

As far as inertial compensators go, I have always subscribed to the theory
that they are merely grav plates mounted in different directions, and tied in
somehow with the nav computer so as to provide a dynamic cancellation of
of the acceleration effects of the maneuver drive.  (e.g., if you have a
6-G maneuver drive burning full out at the tail, in normal physics, you will
be standing on the back wall at six times your normal weight.  If you have
1-G grav plates in the floor, you will feel a "gravity" that is the resultant
of the addition of the two vectors.  If you put six G grav plates at the nose,
that vector cancels the 6-G maneuver drive vector, leaving you with a
comfortable 1-G toward the floor.  Did everyone follow that without the 
diagrams?  )  This probably means that the power consumption of the 
compensators should be tied to the size of the maneuver drive, and should
usually be more than the power consumption of the grav plates.

AGILITY: A NEW SUBJECT

     Pursuant to the above discussions on maneuver drives and inertial
compensators, I'd like to say a few words about the game's concept of agility.
To be brief, it's another crock of...spoiled butter.  The only use of agility
in the game is in combat, where it represents the difficulty of hitting the
ship with a weapon, and I'd like to look at that for the moment.  Agility
is tied to the ship's mass, which is good...it represents the difficulty
of shoving it around in space, so that's rational.  It is calculate by
"dividing the excess energy by the UNLOADED weight of the ship etc.".  I'd
prefer to see this based on the actual weight of the ship, which is usually
something between the loaded weight and the unloaded weight, unless you have
a cargo hold full of metal ingots...but that's not the problem. The first
problem is one of definition.  What is excess energy?  I've always figured
that it was what was left after everything EXCEPT THE MANEUVER DRIVE was 
powered, since it seemed that agility should be a function of maneuver drive.
That being the case, I'd also always assumed that there was a cap on the
energy used for agility equal to the maximum that your drive used.  (If your
drive consumes 65MW, I'd hate to see what it looked like after you ran 2000MW
into it to increase your agility...if those 2000MW aren't going into your
maneuver drive, then you should be able to buy "agility increasers" of some
sort, but that is a can of worms I'd rather not open just now.)

     The second problem is that, as far as I have ever been able to tell,
normal inertial physics are supposed to hold true in the Traveller universe
in everything not related to Jumping.. Right?  So the MT definition of 
agility as "ability to change your heading" is meaningless.  If I have a
ship with a movement vector --------------------------------------->
like that, and I start up my maneuver drive <- like that, except at a small
angle, my vector, which is what people are using to guess where I'm going, to 
put unfriendly laser beams etc in my path, is going to change very slowly.
Some nebulous ability to change my heading  (What, the direction my ship is
pointing??? If I rotate 180 degrees about my present course, I'm still 
flying very fast tail first across the universe) is not going to prevent
somebody from predicting my course well enough to get a missile within 
intercept range.  

As a first approximation, I'd say that your "agility" rating ought to be 
equal to your acceleration rating, as figured above where it depends on
mass, minus whatever loss of acceleration you have by shunting power to your
weapons instead of your engines, PERHAPS modified by some measure of your
rotational inertia if you want to be a completist (a spherical ship should
be able to rotate faster to bring the maneuver drive to a new heading than
a needle shaped ship.)

Now, all of this brings up another question regarding space combat...do energy
weapons actually aim for an enemy ship, or does the firing vessel attempt to
predict the location of the target, and then spray the beams around the 
estimated target locus in an attempt to get a random hit(s) by volume of fire?
In either case a "realistic fix" to the combat system should account for
speed of light lag on detectors (at a greater distance the future position
of the target becomes more uncertain as your data is more out of date) and the
relative speeds of the two vessels (again, adds more uncertainty to the 
location of the target.  The difference would be that in the first case, you
could gain something in defensive ability by using thrust of whatever source
to shove you from "side to side" along your base vector to throw off the 
enemy's prediction programs, or for that matter simply pulse your maneuver 
drive in random power levels at short intervals, (Say 1.5 to 2.0Gs in a 5 
second pattern--better have inertial compensators or the spacesickness will 
be fierce ;-)  ), but in the second case that would be less
effective, more like trying to dodge a shotgun blast after it has had time to 
spread. In either case, a missile that retains maneuver capability for the
final interception would be less affected by "small" movements on the part
of the target.  Missile hits, though, should possibly be strongly affected by
relative motion...if your missile is closing at 6-G with a high speed on a
vessel headed straight at it and also accelerating, it would have less
time to use it sensors and drive to effect the final interception, and would
therefore probably be more likely to miss.

HULL ARMOR, CONFIGURATION AND DAMAGE POINTS

     A few more ideas to think about for the vehicle system redesign.  As
Scott Kellogg pointed out, the results you get when you apply current 
technology to the spacecraft minimum armor requirement of "40" can be
ludicrous.  Why not do away with it entirely?  It would involve the following
changes to the overall game system.  The spaceship combat system is based
on the High Guard system, with the old armor levels 0-9+ being replaced by
the new armor levels 40--, with each old "1" equal to "3" new for combat 
effects.  At a minimum, it would need to be reconfigured with a new base 
value other than "40", at a maximum be replaced by something fully compatible
with whatever ground vehicle combat system is adopted.  An absolute minimum 
for spacecraft would still need to be established, whether it was based on
armor needed for radiation resistance, structural strength needed to withstand
the effects of the maneuver drive (in which case it could be a sliding scale...
if you wanted a "space only" craft with a max thrust of .005G, you wouldn't 
need much strength), or structural strength necessary to contain a 
one-atmosphere pressure of breathing gas, or some other measure...say heat
shielding minimum for reentry.  ('Course grav vehicles can reenter very 
slowly--as long as it isn't against a planetary defense system.).

     As it stands now, an airframe configuration buys you maximum streamlining,
but we should also be able to set it up so that you can build a grav vehicle
using the new equivalent of the Vehicle Design Sequence to use dynamic lift
provided by wings or a lifting body hull.  If your 2G combat speeder had wings
to hold it up, it would be a 3G combat speeder...(Which reminds me obliquely,
that grav vehicle performance should really be recalculated based on local
gravity, just as aircraft performance should be recalculated based on gravity
and air density.< and composition, to be extremely technical>).  Naturally,
I expect this would cost more, but it wouldn't be that tough to add.  
Contrariwise, at low grav-available tech levels, it might be advantageous for 
some purposes to put in a grav module just large enough to hold up a craft, and
then use jet engines, or even propellers, for thrust.  Also, we should 
possibly consider setting things up so that streamlining has more of an effect
than being a top speed limiter.  If I push a brick with 10 lbs of thrusts,
it won't got as fast as a cone of equal weight pointed the right way. I think
this could be done simply enough by having a little table, no more complicated
than the ground pressure vs P/W to calculate off road speeds.

     I think vehicle damage should be based on something more than volume...I
realize that it was done that way for simplicity's sake, but perhaps a rating
based on unloaded mass would do better.  You need to calculate that number
anyway, and I think that it would be a more accurate "One number guess" of
the comparative damage capacities of, say, a hot air balloon and an M1 tank.

Enough for now.

Rob Dean


-------- TML Message #1740 --------

Archive-Message-Number: 1740
Subject: burst - undigestifier program
Date: Fri, 09 Nov 90 13:59:07 PST
From: James T Perkins <jamesp@metolius.WR>


This program splits a TML digest (or a TML bundle, or any forward- or
digest-format message) on its input stream and seperates it into its
component messages, and mails them back to the invoker.  this may sound
preverse but it's way cool! I know, I didn't think much of it until I
tried it.

>From a mail program that lets you pipe to a program with a "|" command,
you can do: "| burst", for example.  If you can get at a message from a
shell command line, you can do "burst <digest-file".  Have fun folks.

Make sure you read the comment header so you know exactly what it does,
prior to running it.  If you are not on a unix system, with any decent
editor you should be able to extract the source code (all source lines
begin with X).

James
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Traveller Mailing List Administrator	     James T Perkins @ Tektronix, Inc
traveller-request@metolius.wr.tek.com	     Beaverton, Oregon, USA
uunet!metolius.wr.tek.com!traveller-request  "Load Auto/Evade, Beowulf!"

#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  burst.c
# Wrapped by jamesp@metolius on Fri Nov  9 13:53:11 1990
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f burst.c -a "${1}" != "-c" ; then 
  echo shar: Will not over-write existing file \"burst.c\"
else
echo shar: Extracting \"burst.c\" \(5352 characters\)
sed "s/^X//" >burst.c <<'END_OF_burst.c'
X/*
X * NAME
X *	burst - burst a mail digest file and resend the messages to user
X *
X * SYNOPSIS
X *	cat digest-mail | burst
X *
X * DESCRIPTION
X *	Burst takes a MH-style digest or forwarded mail message on
X *	stdin, and seperates it into the individual internal messages.
X *	It then mails all the mail files back to the user running burst.
X *	It knows to ignore the leading digest summary and trailing
X *	digest end marker, as well as empty messages.  It also knows how
X *	to remove "- " from the beginning of "escaped" lines that start
X *	with "- -".
X *
X *	By defining the BURSTUSER environment variable, mail may be sent
X *	to a different user than the person running the burst program.
X *
X * ENVIRONMENT
X *	BURSTUSER, USER, LOGNAME - these hold the user's login name for
X *	the purposes of resending the mail.  If BURSTUSER is not defined,
X *	USER is used.  If USER isn't defined, LOGNAME is used.
X *
X * COMPILATION NOTE
X *	Define -DHAS_MKSTEMP when compiling on systems which have
X *	mkstemp() and no mktemp().
X *
X * AUTHOR
X *	James Perkins, jamesp@metolius.wr.tek.com, 9 Nov 1990
X *	This is shareware; file is freely distributable and modifiable.
X *	I assume no responsibility for use or misuse of this program,
X *	nor do I declare it fit for any particular application.
X *
X * HISTORY
X *	Inspired by a program by Ted Kim, tek@cs.ucla.edu.
X *	Burst was written for members of the Traveller Electronic Mailing
X *	List; contact traveller-request@metolius.wr.tek.com for details.
X *
X * BUGS
X *	Burst assumes a Unix-like mail and execution environment.
X */
X
X#include <stdio.h>
X#include <string.h>
X#ifndef HAS_MKSTEMP
X#include <sys/file.h>
X#endif
X
Xextern char *getenv();
Xextern char *sprintf();
X#ifndef HAS_MKSTEMP
Xextern char *mktemp();
X#endif
X
Xtypedef int bool;
X
X#define TRUE		1	/* for bool types */
X#define FALSE		0	/* for bool types */
X
X#define TMPNAMELEN	60	/* max temporary file name length */
X#define BUFLEN		256	/* max line length handleable */
X#define CMDLEN		256	/* max length for mail system() call cmd */
X
X#define TMPNAME		"/tmp/burstXXXXXXX"	/* tmp file to use */
X#define END_STRING	"End of "	/* first line of end of digest msg */
X#define MAIL		"/bin/mail"	/* mail program to use */
X
X/* macro to see if the beginning of a string matches another string */
X#define STRMATCH(s, t)	(strncmp((s), (t), strlen(t)) == 0)
X
X/* forward declarations */
Xchar *tmp_file_name();
Xbool extract_message();
Xvoid mail_file();
X
Xmain()
X{
X    char *tmp;
X    FILE *fp;
X    int mailable;
X    char *user;
X
X    if ((user = getenv("BURSTUSER")) == NULL)
X    {
X	if ((user = getenv("USER")) == NULL)
X	{
X	    if ((user = getenv("LOGNAME")) == NULL)
X	    {
X		(void)fprintf(stderr,
X		    "burst: can't find USER or LOGNAME envariable\n");
X		exit(1);
X	    }
X	}
X    }
X
X    while (!feof(stdin))
X    {
X	tmp = tmp_file_name(&fp);
X	if (fp == NULL)
X	{
X	    perror(tmp);
X	    exit(1);
X	}
X	mailable = extract_message(stdin, fp);
X	(void)fclose(fp);
X
X	if (mailable)
X	{
X	    mail_file(tmp, user);
X	}
X
X	(void)unlink(tmp);
X    }
X}
X
Xchar *
Xtmp_file_name(fpp)
XFILE **fpp;
X{
X    static char tmpname[TMPNAMELEN];
X    int fd;
X
X    (void)strcpy(tmpname, TMPNAME);
X
X#ifndef HAS_MKSTEMP
X    (void)mktemp(tmpname);
X    fd = open(tmpname, O_CREAT | O_RDWR | O_EXCL, 0644);
X#else    
X    fd = mkstemp(tmpname);
X#endif    
X    if (fd == NULL)
X    {
X	*fpp = NULL;
X    }
X    else
X    {
X	/* wrap stdio info around filedes */
X	*fpp = fdopen(fd, "w");
X    }
X
X    return tmpname;
X}
X
X/*
X * Read to the next line commencing with a pair of dashes. Store all
X * this in the output file. Delete any leading blank lines. Any line
X * beginning with "- -" should have the leading "- " deleted. the
X * terminating line, beginning with a pair of dashes, is not to be
X * echoed.
X *
X * If this is the first message extracted or the first nonblank line
X * matches END_STRING, or there is no text to the message, return code
X * mailable FALSE. Otherwise, return mailable TRUE.
X */
X
Xbool
Xextract_message(fin, fout)
XFILE *fin, *fout;
X{
X    static bool first_time = TRUE;
X    bool leading = TRUE;
X    char buf[BUFLEN];
X    bool mailable = TRUE;
X
X    if (first_time)
X    {
X	/* don't mail header */
X	first_time = FALSE;
X	mailable = FALSE;
X    }
X
X    while (!feof(fin))
X    {
X	if (fgets(buf, sizeof(buf), fin) == NULL)
X	{
X	    /* no dash line seperator - this definitely isn't mailable */
X	    mailable = FALSE;
X	    break;
X	}
X
X	if (STRMATCH(buf, "--"))
X	{
X	    /* two dashes - end of message */
X	    break;
X	}
X
X	if (leading && STRMATCH(buf, "\n"))
X	{
X	    /* blank leading line - eat it */
X	    continue;
X	}
X
X	if (leading && STRMATCH(buf, END_STRING))
X	{
X	    /* tail of digest - don't mail this */
X	    mailable = FALSE;
X	}
X
X	/* first line of message text */
X	leading = FALSE;
X
X	if (STRMATCH(buf, "- -"))
X	{
X	    /* escaped dash line - echo, deleting leading "- " */
X	    fputs(buf + 2, fout);
X	}
X	else
X	{
X	    /* normal line - echo */
X	    fputs(buf, fout);
X	}
X    }
X
X    if (leading == TRUE)
X    {
X	/* No text in the mail message */
X	return FALSE;
X    }
X
X    return mailable;
X}
X
X/*
X * Mail the tmp file to the user
X */
X
Xvoid
Xmail_file(tmpfile, user)
Xchar *tmpfile;
Xchar *user;
X{
X    char cmd[CMDLEN];
X    int code;
X
X    (void)sprintf(cmd, "%s %s <%s", MAIL, user, tmpfile);
X    if ((code = system(cmd)) != 0)
X    {
X	(void)fprintf(stderr, "burst: command \"%s\" returned exit code %d\n",
X	    cmd, code);
X	exit(code);
X    }
X}
END_OF_burst.c
if test 5352 -ne `wc -c <burst.c`; then
    echo shar: \"burst.c\" unpacked with wrong size!
fi
# end of overwriting check
fi
echo shar: End of shell archive.
exit 0

-------- TML Message #1741 --------

Archive-Message-Number: 1741
Date: Fri, 9 Nov 90 07:40:37 EST
From: Dave Allen <dallen@viewlogic.COM>
Subject: Sysgen and USML

Hi!
There have been some inquiries recently about the System Generation sublist.
I would like to recount a little history.  In early 1988, a USENET discussion
on system generation spawned a short-lived mailing list called the Universal
Simulation Mailing List (USML).  I was one of the co-originators of the
discussion.  The USML was an indirect ancestor of the Trav System Generation
sublist; some of the members were the same.  The Sysgen sublist also died out.

All of the USML archives are still on line and available via anonymous FTP.
There are some interesting discussions there, and also some programs.  These
archives, obviously, do not include the stuff related to the Sysgen sublist.
I don't know where/if that stuff is kept.  The USML archive is on a machine
called topgun.agps.lanl.gov.  Here is a listing of what was there last week.

cd pub/usml
ls -l
- - -rw-r--r--  1 -2          25957 Sep 14  1988 Actual
- - -rw-r--r--  1 -2         107641 Jul 28  1989 Archive
drwxr-xr-x  2 -2            512 Nov 16  1988 Digests
drwxr-xr-x  2 -2            512 Aug 23  1989 List
- - -rw-r--r--  1 -2          41639 Sep  8  1988 OtherSun.src
- - -rw-r--r--  1 -2         109856 Sep 15  1988 Psychohistory
- - -rw-r--r--  1 -2           3731 Nov 17  1988 README
drwxr-xr-x  2 -2            512 Sep 23  1988 Universe
- - -rw-r--r--  1 -2          54294 Sep 15  1988 accrete.c
- - -rw-r--r--  1 -2          49459 Sep 19  1988 accretion.amiga
- - -rw-r--r--  1 -2          67778 Sep 10  1988 accretion.src
- - -rw-r--r--  1 -2         176121 Jan 18  1989 archive
- - -rw-r--r--  1 -2         169887 Jul 27  1989 cellsim_1.5.tar.Z
- - -rw-r--r--  1 -2           5334 Sep  8  1988 fractal.c
- - -rw-r--r--  1 -2          29897 Sep 20  1988 plates.c
- - -rw-r--r--  1 -2          10495 Sep 21  1988 references
- - -rw-r--r--  1 -2          30148 Sep 14  1988 shebs
- - -rw-r--r--  1 -2          39275 Sep 22  1988 siod.c
- - -rw-r--r--  1 -2          58063 Jan 11  1989 starcul.shar
- - -rw-r--r--  1 -2          75683 Nov 16  1988 starform
- - -rw-r--r--  1 -2          60385 Sep  8  1988 system.arc
- - -rw-r--r--  1 -2          65536 Jan 28  1989 traveller.tar
- - -rw-r--r--  1 -2         761043 Sep 16  1988 xc5.1-tar.Z

Get the README file.  I recommend starform, an excellent true-astrophysics
system generation program by Matt Burdick.

Enjoy!
- - - Dave Allen: dallen@viewlogic.com, Viewlogic Systems, Marlboro, Mass

-------- TML Message #1742 --------

Archive-Message-Number: 1742
Date: Fri, 9 Nov 90 10:14:48 EST
From: Fiver Toadflax <09nilles%cuavax.dnet@netcon.cua.edu>
Subject: Black Globes

re:moving through the field.

In the history of the black globe, found in High Guard I believe, it
tells of when the first black globe was activated.  It cut off the arm
of the scientist activating it.  So I would venture a guess that it is
not possible to move through the field however slowly.

Though it does present a good question about what happens when matter
meets the field. after all       2
                             E=mc

Dave
09nilles@cua.bitnet

-------- TML Message #1743 --------

Archive-Message-Number: 1743
Date:     Fri, 9 Nov 90 15:32:11 EST
From: "Robert S. Dean" <rsdean@crdec8.apgea.army.mil>
Subject:  Black Globes revisited

Having left my rules at home today, I am winging this response.  I would agree
with everyone who traces the origin of the black globe to Pournelle's Langston
Field (I think it showed up in a Pournelle book set in that universe prior to
the collaberation with Niven on Mote, but I could be wrong.)  

In any case, to refer to the current Travller black globe as "the ultimate
defense" when it will eventually overload and destroy your ship in a huge
explosion is, in my opinion, overstating the case a trifle.  Now if someone
who has the books handy can tell me how much energy the globe needs to be
overloaded on, say a 100,000ton ship with a Jump-4 drive (I think we still
use the jump drive as an energy sink even though the Starship Operators
Manual has disallowed jumping using the stored energy) we could make a
considered opinion.  

All I remember is that in High Guard, I never considered it worthwhile
because the addition to the armor class while flickering with any BG generator
you could build in the Imperium didn't seem to be worth the possibility of
being blown to atoms by the overload.  This leaves out the tactical surprise
considerations.  (And so without reanalyzing the situation, you won't find BGs
on my latest imperial navy design proposals.)

Rob Dean


-------- End of TML Messages --------

